More user friendly time-shift buffer

ABSTRACT

A PVR device ( 10 ) having a varying size time-shift buffer ( 22 ) that provides a guaranteed minimum replay time for a more consistent consumer experience. The PVR device includes a video data storage means ( 24 ), a video input means ( 12 ), a video output means ( 32 ), a user input means ( 28 ), an input module ( 30 ) for receiving the video input data and writing the video input in the time-shift buffer ( 22 ), an output module ( 32 ) for reading the written video data from the time-shift buffer ( 22 ) and displaying it via the video output means ( 32 ) and a trimming module ( 42 ) for reducing the size of the time-shift buffer ( 22 ).

This invention relates to the display of video or audiovisual imagesfrom a streaming type of input over a period of time in a computerenvironment such as a Personal Video Recorder (PVR) and, in particular,to devices and methods wherein the video images may be displayed withfeatures such as time delay and instant replay.

Multimedia devices such as VCRs, DVD players, MP3 players, cassetteplayers, CD players and, in particular, PVRs have become popular withconsumers in recent years. It is desirable for a user of time-varyingvideo images displayed by VCRs, DVD players and PVRs to be able to pausethe display of the video images. Previously, this has been done byhalting the display when the user supplies an appropriate instruction,then beginning the display again, at the point at which the display washalted, when the user supplies another appropriate instruction. Forpre-recorded video images (e.g., the video on a DVD disc), theimplementation of such pausing is straightforward, since all of thevideo data is already stored on a storage medium and can be accessed asdesired. The capability to pause the display of pre-recorded images hasbeen implemented in most consumer electronics equipment that is used todisplay pre-recorded video images.

A difficulty is encountered in implementing the above-describedconventional pausing method for images that are not pre-recorded, but,rather, are represented by video data that is only momentarily availableto the video display system. This is the case, for example, with thebroadcast of a television or radio program, or with a streaming type ofinput over a network such as the Internet or a local wireless network.

The current hard disk-based personal video recorder (PVR) systems offera common technical feature known as the Time-shift Buffer. Thistime-shift buffer offers users features such as being able to pause thet.v. and perform an instant replay, and then to continue viewing fromthe point where the t.v. was paused. The time-shift buffer is alwaysrecording the channel that the user is watching, however, the oldestvideo in the buffer is continuously being discarded. Typicalimplementations in use today offer a fixed-time buffer having, forexample, a one half hour total viewing time.

Current technologies having a fixed size time-shift buffer can, however,present difficulties or problems for a user. For example, if a user iswatching with a time shift nearly equal to the fixed size of thetime-shift buffer, the ability to go back further is severely hampered.As an example, if the time-shift buffer is fixed at 30 minutes and theuser is watching with a time-shift of 29 minutes, the user can now onlygo back 1 more minute.

It is desirable, therefore, to provide a system and method that providesa time-shift buffer that is not fixed in size, in order to offer aguaranteed minimum replay time to a user of the system.

In accordance with one aspect of the present invention, a PVR deviceincluding a varying size time-shift buffer is provided, wherein thetime-shift buffer provides a guaranteed minimum replay time. The PVRdevice includes video data storage, a video input, a video output, auser input, an input module, an output module and a trimming module forreducing the size of the time-shift buffer.

In accordance with another aspect of the present invention, a method forproviding a user-friendly time-shift buffer is provided. The methodincludes acquiring input video data from a video input, extending atime-shift buffer on a recordable medium with the acquired video data,reading selected video data from the time-shift buffer, displaying theselected video data read from the time-shift buffer via a video outputand trimming the time-shift buffer at a chronological beginning of thetime-shift buffer, wherein the trimming does not reduce an availablereplay time below a guaranteed minimum replay time.

One advantage of the present invention is provided by the ability of thetime-shift buffer to grow.

Another advantage is that if the user pauses the display even forextended duration, the time-shift buffer grows automatically if the userincreases the length of a time delay when viewing.

Another advantage of the present invention is the ability to provide aguaranteed minimum replay time.

Yet another advantage is the more consistent consumer experienceprovided by the present invention.

Still further advantages of the present invention will become apparentto those of ordinary skill in the art upon reading and understanding thefollowing detailed description of the preferred embodiments.

The invention may take form in various parts and arrangements of parts.The drawings are only for purposes of illustrating a preferredembodiment and are not to be construed as limiting the invention.

FIG. 1 is a block diagram of a PVR system in accordance with the presentinvention;

FIG. 2 is a schematic diagram of a PVR system according to a preferredembodiment of the present invention;

FIG. 3 is a schematic diagram of a PVR system according to an alternateembodiment of the present invention;

FIG. 4 is a flow chart of an input method according to an embodiment ofthe present invention;

FIG. 5 is a flow chart of an output method according to an embodiment ofthe present invention; and

FIG. 6 is a flow chart of a trimming method according to an embodimentof the present invention.

With reference to FIG. 1, input video data is acquired from a videosource by input video interface 12 and transmitted via system bus 14under control of CPU 16 which is running a PVR program 18 residing insystem memory 20. The video, under control of PVR program 18, is thenwritten to time-shift buffer 22 residing on a hard disk 24 andsubsequently, or simultaneously, transmitted to output video interface26 for display on a user display device.

The time-shift buffer is not kept at a constant total size, but rather aconstant size relative to the current playing position. For example, ifthe time-shift buffer is set to a size of 10 minutes, but the user iswatching with a time shift of 15 minutes, the buffered video would bekept at 10+15 or 25 minutes. This solution has the advantage that theconsumer gets a more consistent experience that is independent of thetime shift with which the user is watching. While the time-shift bufferis described as being of a constant size relative to the current playingposition, the constant size is with respect to frames, however, the sizein terms of the number of bytes may vary.

Also shown in FIG. 1 is a user input interface 28 for receiving userinput commands regarding events such as: pausing, replaying, orcontinuing in a normal or accelerated, fast-forward mode. Any number ofinput commands can be communicated via user controls 29 on userinterface 28, as are typical in hand-held remote controllers.

When a user of the system 10 pauses the display of the image on thedisplay device attached to the output video interface 26, the PVRprogram 18 directs the video received through the input video interface12 via the system bus 14 to the time-shift buffer 22 on the hard disk24. When the user ends the pause, the system PVR program 18 causes thestored displayed data in the time-shift buffer 22 to be transmitted fromthe hard disk 24 to the output video interface 26 via the bus 14.Essentially, simultaneously, incoming input video from input videointerface 12 is written to the time-shift buffer 22 for viewing at anappropriate time. However, in order for the time-shift buffer 22 to notgrow to an unacceptably large size, it is concurrently trimmed tomaintain a selected size. If a user prefers, video information from thetime-shift buffer 22 that has been delayed can be transmitted to theoutput video interface 26 in an accelerated mode so that, in time, theuser is displaying essentially real time data with a minimal time delay.

With respect to the time delay, although it is desirable to minimize thetime delay, it cannot be entirely eliminated due to hardware and otherlatency considerations. For example, it is difficult in a system to havea read position very close to a current write position. This results ina small, but sometimes noticeable delay, for example when changingchannels and there is a momentary delay before the selected channelappears.

FIG. 2 provides a logical diagram of how the PVR program 18 (of FIG. 1)is organized and operates in conjunction with the disk buffer 22. ThePVR program 18 includes an input module 30 for reading the video input,an output module 32 for providing the video output to output interface26, and a controller module 34 for controlling the operation of theinput module 30 and the output module 32. It is to be understood thatthe video input screen being received by the video input interface 12may be in any number of video formats. It may be an analog video inputor any number of digital video input formats. The input module 30converts the input video stream to a preferred format for storing invideo buffer 22.

The video-buffer 22 is sub-divided into individual segments known as agroup of pictures (GOP). If, for example, the preferred video format forthe video buffer 22 is MPEG2, each GOP will begin with an I-framefollowed usually by a number of P and B frames. Each GOP can be as smallas a single I-frame, but is usually no more than 15 frames in length forMPEG2. I-frames are intra-coded frames with an average 7 to 1 reductionratio. P-frames are predicted based on prior I or P frames with theaddition of data for changed macro blocks. P-frames average a 20 to 1reduction ratio or about half the size of I frames. B-frames arebidirectionally predicted frames based on appearance with positions ofpast and future frame macro blocks. B-frames have less data thanP-frames averaging about a 50 to 1 reduction ratio. In the case whereMPEG4 is the selected format for the video buffer 22, each GOP 36 can beas large as the maximum key frame interval, usually 200 to 300 frames.

In the following description, references are made to video frames withrespect to reading, writing and buffering. However, it is to beunderstood that, in many environments, operations may take place withchunks of data that include multiple frames, e.g., GOPs. Conversely, itis possible that one frame may comprise multiple packets of data.However, for ease of understanding the present invention, alldescriptions herein are made with reference to frames but are intendedto include implementations utilizing chunks or packets of data.

The video buffer 22 may be implemented utilizing all or part of astorage device, e.g. a hard drive, using functions developedspecifically for the system 10. However, the video buffer 22 may also beimplemented in existing files systems. For example, in one embodiment,the video buffer 22 is a regular file within a native file system undercontrol of a file system module 37 of the particular operating systemused for this embodiment. If the PVR system is implemented using a UNIXoperating system, the video buffer 22 is preferably a regular file usinga standard UNIX file system. If, however, the operating system is aLINUX operating system, the video buffer 22 is preferably a regular filewritten to, for example, the second extended file system (EXT2). If aBSD operating system is utilized, the video buffer 22 is preferably aregular file using the BSD file system. In this embodiment, any moduleacting upon time-shift buffer 22 communicates via system calls to filesystem module 37 in order to perform the desired actions.

In the preferred embodiment, the video buffer 22 is written utilizingthe MPEG2 format and the input stream received from the video inputinterface 12 is also an MPEG2 format. However, it is to be understoodthat any number of input stream formats and any number of video formatsfor the video buffer 22 are also included within the scope of thepresent application.

As the input module 30 receives video frames from the video inputinterface 12, it writes individual frames to the video buffer 22 whichhas been previously described as a standard file in the native filesystem of the preferred operating system. The input module 30 maintainsa write pointer 38 which is essentially a count of bytes or frameswritten to the video buffer 22. Essentially simultaneously, the outputmodule 32 reads video frames from the video buffer and provides theoutput frames to the output interface 26 for display to a user on adisplay device.

The output module 32 maintains a read pointer 40 which is a pointer tothe currently viewed frame in the video buffer 22. As the output modulereads frames from video buffer 22, the read pointer 40 is incremented tothe next frame in the video buffer. Furthermore, the input module 30 andthe output module 32 operate under direction from the controller module34. For example, a user with the user device 28 may wish to turn thepersonal video recorder system 10 off. In this case, the controllermodule 34 indicates to the input module 30 to close the video buffer 22file and discontinue writing to the file. At the same time, the outputmodule 32 discontinues providing the video frames to the outputinterface 26. Or, for example, in the case where a user wishes to pausethe display momentarily, the controller module 34 then signals theoutput module 32 that it should suspend reading from the buffer 22 andcontinue displaying the currently read frame from the video buffer 22.In this case, however, the input module 30 continues to write frames tothe video buffer 22.

In normal operation, in order to keep the size of the video buffer 22from growing indefinitely, as the input module 30 writes new outputframes to the buffer 22 at the end of the native file, a trimming module42 removes frames from the beginning of the video buffer 22. Theseframes that have been trimmed from video buffer 22 are represented bythe dashed segments indicated by numeral 44. In order to maintain aguaranteed replay time for the user, the trimming module 42 examines theread pointer 40 and calculates available replay time frames 46 byexamining the displacement from the beginning of the file indicated bythe read pointer 40. Then the trimming module 42 removes an appropriatenumber of frames from the beginning of the video buffer 22, and the readpointer 40 and the write pointer 38 are adjusted accordingly. The numberof frames trimmed from the beginning of the file is reduced in numbersuch that the read pointer 40 and the write pointer 38 representdisplacements in bytes or frames from the beginning of the native file.

The trimming module 42, when trimming the beginning of the time-shiftbuffer 22 in a native file system, preferably performs the trimming in amanner that conforms to the file format of the system. Because of this,the trimming function does not always remove precisely the number ofbytes requested, but instead removes the largest number of requestedbyes possible while abiding by allocation unit restrictions of theparticular file system.

In the case where a user has paused the display momentarily and thenresumed viewing, a disparity will occur between the read pointer 40 andthe write pointer 38, indicating the delayed frames 48 when the user isviewing with a time delay. In this manner then, the video buffer 22grows in size so that its total size includes a guaranteed availablereplay time represented by the frames 46 and a delayed time representedby the added frames 48. Thus, as the video buffer 22 is trimmed at thebeginning of the file by trimming module 42, it concurrently grows atthe opposite end of the video buffer 22 by records, frames or GOPswritten by the input module 38. The future records, frames or GOPs whichare not yet written to the video buffer 22 are represented by numeral50.

The Video buffer 22 is represented in FIG. 2 in a linear fashion inorder to distinguish it from the typical circular buffer used inexisting PVRs. In the instant application, however, a native file iswritten and trimmed simultaneously, and essentially worms its waythrough free space in the native file system.

As an optional feature of the PVR system 10, when the user is viewing inreal time, the input module 30 may simultaneously write to the videobuffer 22 and place each video frame in a real-time buffer 52. Insteadof reading frames from the video buffer 22, the output module retrievesframes directly from memory in the real-time buffer 52 for display. Thisimproves the viewing experience by further minimizing any time delaycaused by the aforementioned reaction latencies in the system. Thereal-time buffer 52 is preferably maintained in random access memory(not shown). Also, while the real-time buffer is shown with a singleelement, in typical implementations, the buffer includes multipleelements in the form of a queue.

FIG. 3 is a representation of an alternate embodiment of the presentapplication similar to that shown in FIG. 2 wherein like numeralsrepresent like elements or processes. However, the video buffer 22 isimplemented in a different fashion in the embodiment illustrated in FIG.3. Instead of being part of a single file in a native file system, eachof the segments 36 in the video buffer 22 is a separate file. The videobuffer 22 includes a plurality of files.

In this embodiment, the video buffer 22 is illustrated as a circularbuffer. However, the buffer 22 can grow and shrink in size according toneed. A methodology for growing or shrinking the video buffer 22 issimilar to the embodiment illustrated in FIG. 2. However, in thisembodiment, the input module 30, which utilizes the write pointer 38,has an associated file table 60 which represents file names in achronological fashion, video time-wise.

If the user is viewing the video at a normal rate, the video buffer 22neither grows nor shrinks. The write pointer 38 accesses files in asequential fashion through the video buffer 22, recursively circulatingthrough the file names in the file table 60. Essentially,simultaneously, the output module 32 accesses files indicated by theread pointer 40 which is also associated with file table 60 andrecursively retrieves files from video buffer 22, with or without theoutput delay 48. If, however, the user indicates a desire to pause theoutput display, the read pointer 40 stops advancing through the videobuffer 22. In order to maintain a guaranteed available replay time,files corresponding to files 46 are inserted into the video buffer 22.At the position in the file table 60 associated with the write pointer38, new files are generated in the native file system and inserted inthe file table 60. In this manner, the available replay time is notdiminished and the video buffer 22 continues to grow while the userremains in a pause mode. If, however, a user resumes viewing at a normalrate with a fixed delay, the write pointer 38 and the read pointer 40continue to advance in a circular fashion or a recursive fashion throughthe video buffer 22 by accessing files via the file table 60.

When the user subsequently advances the display at a faster rate by fastforwarding, skipping commercials, or jumping to real time viewing, thetrimming module 42 removes files from file table 60 to reduce theavailable replay time to the guaranteed replay time. The video buffer 22shrinks accordingly.

In FIG. 4, an input method 70 suitable for use in an implementation ofthe input module 30 is diagramed. In step 72, a video frame is acquiredfrom the input video interface 12. Step 74 is an optional step for theabove-described real-time buffer 52 in which a test is made to determineif the real-time buffer 52 has been blocked by the output module 32. Ifthe buffer 52 has not been blocked, processing continues at step 76which copies the video frame to the real-time buffer 52. Subsequently,in step 78, a real-time buffer 52 is blocked by input method 70. Afteroptional steps 74-78, in step 80 the video buffer 22 is extended as thevideo frame is written to the video buffer 22, extending the file in thenative file system with the currently acquired video frame. In step 82,the write pointer is incremented accordingly to represent thedisplacement to the new last frame in the video buffer 22.

In FIG. 5, an output method 90 suitable for implementation in outputmodule 32 is diagramed. An optional step 92, determines if the user isviewing in real time without any delay. If the answer is

yes

, processing continues. In step 94, the output method 90 waits for thereal-time buffer 52 to be blocked by the input method 70. After thebuffer has been blocked by the input module or input method 70, a step96 reads a video frame from the real-time buffer 52 for display on theoutput device. If a negative answer was determined in step 92, a step 98determines if the user has requested a pause in the display. If no pausehas been requested, processing continues at step 100 which acquires avideo frame from the file representing video buffer 22, at a pointrepresented by the read pointer 40, for display on the output device. Instep 102, the read pointer is incremented to point to the video framethat will be next acquired. In all cases, processing continues at step104 where the above-acquired video frame is displayed by being passed tothe output interface 26. In optional step 106, the real-time buffer 52is unblocked for subsequent processing by the input method 70.

In FIG. 6, a trimming method 110 suitable for the trimming module 42 isdiagramed. In step 112 of the trimming method, exclusive access to theread pointer 40 and the write pointer 38 is acquired such that the inputmodule 30 and the output module 32 are not accessing the pointerssimultaneously. In step 114, the available replay time is calculated byexamining the read pointer 40 with respect to the beginning of the file(FIG. 2) or by examining the read pointer 40 with respect to the writepointer 38 (FIG. 3). Subsequently, in step 116, the available replaytime is compared to the guaranteed replay time. If the available exceedsthe guaranteed replay time, step 118 is invoked to trim the beginning ofthe file to the point where the available replay time is equal to theguaranteed replay time. In any case, step 120 releases the read pointer40 and the write pointer 38 for access by the output method 32 and theinput method 30.

It is to be understood that, while the input module 30, the outputmodule 32, the controller module 34, and the trimming module 42 havebeen shown and described as operating as independent processes in a-multi-threaded environment, the above-described modules may be combinedinto a single module operating as a single thread, in which the modulesiteratively perform processing steps in a sequentially ordered manner.

The invention has been described with reference to the preferredembodiments. Obviously, modifications and alterations will occur toothers upon reading and understanding the preceding detaileddescription. It is intended that the invention be construed as includingall such modifications and alterations insofar as they come within thescope of the appended claims or the equivalents thereof.

1. A video recorder comprising: means for recording input video data ina time-shift buffer on a portion of a recording medium; means forreading video data from the time-shift buffer; means for independentlytrimming video data at a chronological beginning of the time-shiftbuffer to maintain at least a guaranteed minimum available replay timebetween the chronological beginning of the time-shift buffer and thevideo data read at a current time; means for pausing the reading of thevideo data from the time-shift buffer to pause a current read time;means for independently enlarging the time-shift buffer at achronological end of the time-shift buffer with currently input videodata.
 2. The video recorder as set forth in claim 1, wherein thetime-shift buffer comprises a single file.
 3. The video recorder as setforth in claim 2, wherein the recording medium is a hard drive.
 4. Thevideo recorder as set forth in claim 3, wherein the single file ismaintained within a native file system of an operating system includedon the video recorder.
 5. The video recorder as set forth in claim 1,wherein the time-shift buffer includes a plurality of files.
 6. Thevideo recorder as set forth in claim 5, wherein the recording medium isa hard drive.
 7. The video recorder as set forth in claim 6, wherein theplurality of files are maintained within a native file system of anoperating system included on the video recorder.
 8. The video recorderas set forth in claim 7, further including a means for performingoperations on the plurality of files.
 9. The video recorder as set forthin claim 1, further including: means for terminating the pausing of thereading of video data, such that reading of the video data from thetime-shift buffer is recommenced.
 10. The video recorder as set forth inclaim 1, further including: means for fast-forwarding through the videodata in the time-shift buffer; and means for contracting the size of thetime-shift buffer.
 11. The video recorder as set forth in claim 1,further including: a real-time buffer, the input module passing videodata to the output module via the real-time buffer when a user isviewing in real time without a time delay.
 12. A video recordercomprising: a hard drive; a varying size time-shift buffer on the harddrive, which provides a guaranteed minimum replay time; an input modulefor receiving the video input data and writing the video input data tothe time-shift buffer on the hard drive; an output module for readingthe written video from the time-shift buffer and displaying it via theoutput video interface; and a trimming module for adjusting the size ofthe time-shift buffer, such that the size of the time-shift buffer issufficient to maintain the guaranteed minimum replay time.
 13. The videorecorder as set forth in claim 12, such that the hard drive includes atleast one standard file system for holding the time-shift buffer. 14.The video recorder as set forth in claim 13, further including a filesystem module for adding, deleting and maintaining files on the at leastone standard file system.
 15. The video recorder as set forth in claim14, wherein the time-shift buffer comprises a single file.
 16. The videorecorder as set forth in claim 14, wherein the time-shift bufferincludes a plurality of files.
 17. The video recorder as set forth inclaim 12, further including: a first user control for alternatelypausing and recommencing the reading of the video data from thetime-shift buffer.
 18. The video recorder as set forth in claim 17,further including a second user control for fast-forwarding the readingof the video data from the time-shift buffer.
 19. The video recorder asset forth in claim 12, further including: a read pointer utilized by theoutput module for pointing to the appropriate segment to be read fromthe time-shift buffer; and a write pointer utilized by the input modulefor pointing to the appropriate segment to be written in the time-shiftbuffer.
 20. The video recorder as set forth in claim 19, furtherincluding a real-time buffer, the input module passing video data to theoutput module via the real-time buffer when a user is viewing in realtime without a time delay.
 21. A method of time-shift bufferingcomprising: recording input video data in a time-shift buffer on aportion of a recording medium; reading video data from the time-shiftbuffer; independently trimming video data at a chronological beginningof the time-shift buffer to maintain at least a guaranteed minimumavailable replay time between the chronological beginning of thetime-shift buffer and the video data read at a current time; pausing thereading of the video data from the time-shift buffer to pause a currentread time; independently enlarging the time-shift buffer at achronological end of the time-shift buffer with currently input videodata.
 22. The method as set forth in claim 21, further including:terminating pausing the reading of video data, such that reading of thevideo data from the time-shift buffer is recommenced; and when thereading of the video data is recommenced, freezing a size of thetime-shift buffer.
 23. The method as set forth in claim 22, furtherincluding: fast-forwarding through the video data in the time-shiftbuffer; and contracting the size of the time-shift buffer.
 24. Themethod as set forth in claim 21, further including: fast-forwardingthrough the video data in the time-shift buffer; and contracting thesize of the time-shift buffer.
 25. The method as set forth in claim 21,such that the input module, the output module and the trimming moduleoperate as separate processes.
 26. The method as set forth in claim 21,such that the input module, the output module and the trimming moduleoperate as a single-thread process.
 27. The method as set forth in claim21, further including: storing input video data in a real-time buffer;and reading video data from the real-time buffer, such that the readingvideo data from the real-time buffer is performed when a user is viewingat a real-time rate without a time-delay.
 28. A method for controllingthe size of a time-shift buffer comprising: writing current data to achronological end of the time-shift buffer, thereby increasing the sizeof the time-shift buffer; determining a size by which the time-shiftbuffer is to be reduced; trimming a chronological beginning of thetime-shift buffer by a largest possible size not exceeding thedetermined size.
 29. The method as set forth in claim 28 wherein thewriting and the trimming are performed within a native file system andthe time-shift buffer conforms to standards of a file in the native filesystem.